IBIS Macromodel Task Group Meeting date: 30 August 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma * Jared James Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Ming Yan Radek Biernacki Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Rivos Yansheng Wang SAE ITC Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Waymo: Zhiping Yang Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. (Note: After the meeting, the group decided via email vote to cancel the meeting scheduled for September 6th). ------------- Review of ARs: - Zhiping to send his presentation and Hanfeng's to the ATM list. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 23rd meeting. Michael moved to approve the minutes. Ambrish seconded the motion. There were no objections. -------------- New Discussion: Supporting PI simulation in IBIS: Kinger reviewed a draft proposal for incorporating the Standard Power Integrity Model's (SPIM) concepts into IBIS. He noted that Bob had helped with feedback on the proper format of the tree structure for a .spim file, and he said the draft was based on what had been presented at past EMC+SIPI IBIS Summits: https://urldefense.proofpoint.com/v2/url?u=http-3A__ibis.org_summits_aug20_cai.pdf&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=WbM2LNEQ-JonHdPewIZWQ0QmU46yEC7ZZbijb444ldLCS5cjXz2ArIwy3nz_elnq&s=qDSw9OveNGHUUke36Ch86TqTS3IXRJKQVeleuavp2s4&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__ibis.org_summits_aug22_yang.pdf&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=WbM2LNEQ-JonHdPewIZWQ0QmU46yEC7ZZbijb444ldLCS5cjXz2ArIwy3nz_elnq&s=pp6rVr8WY2PlU4hUqElDTRPsM0NWeNcyehf1hCbNuO4&e= Kinger reviewed the draft's Definition of the Issue section and highlighted important points. He said existing IBIS power-aware models were focused on I/O rails and typically further restricted to only the analog front-end circuit block. The existing IBIS models do not cover all the power supply rails (control circuit block, analog block, reference-clock block). For the PI domain there is more emphasis on the high-current rails of a CPU, GPU, NPU. Current power-aware models in IBIS don't address this. He said the authors of the BIRD draft are coming from the high-current rail perspective initially, but they want want to provide a framework that can ultimately be expanded for I/O rails too. Kinger said the goal is to provide platform designers much more flexibility. He said many chip vendors only provide PI design information in the form of a physical equivalence. The goal of providing SPIM information in IBIS is to provide platform designers with a behavioral electrical model. This protects a chip vendor's IP but provides the platform designer with more flexibility in creating a design that meets the PI design target. He noted that system level designers may prefer to have all the information a chip vendor's in-house design team has, but chip vendors don't want to share that much. With SPIM an electrical model for design targets up to around 20MHz could be provided to system level designers. Kinger noted that Michael had proposed that the contents of a [Begin Chip SPIM] [End Chip SPIM] block also be allowed in an .ibs file, as well as a stand-alone .spim file. Kinger said we would allow one of these blocks per [Component], as it's a component SPIM definition. Individual [Begin SPIM] [End SPIM] blocks are provided for each power rail and therefore may occur multiple times within a Chip SPIM block. Kinger noted that in the new tree hierarchy the [SPIM Stimulus] and [SPIM Target] were shown as occurring below the [SPIM Touchstone File Name]. He questioned whether this was correct, and said he considered them to be at the same level as [SPIM Touchstone File Name] conceptually. Kinger reviewed the new SPIM keywords intended to support DC simulation. He reviewed the [SPIM Rnetwork File Name] and said it captures a model extracted from each BGA to the port group bumps. These R models capture the effects of the package and support DC power simulation. Kinger reviewed the SPIM model's definition of local references. He said that SPIM models look to include "nearby" GND pins. He said that using all pins for a given rail as the reference leads to unrealistic models with apparent impedances lower than they should be. He said their experience suggested that including all rail pins within about 3x the BGA pitch provided the best trade off between accuracy and simulation speed. The [SPIM Pin Groups] is used to define these groupings, and the grouping are then used in the [SPIM Port List]. As a suggestion, Kinger wondered whether we should add a 4th column "port function" to the [SPIM Port List] to differentiate between sensing ports, stimulus ports, and BGA balls. He said that at a minimum 3 port definitions would be required in a [SPIM Port List], one each for stimulus, sensing, and a BGA ball. Kinger commented on the optimal number of ports for the Touchstone file. He said that even with devices including several thousand bumps and several hundred BGA balls, they typically recommend about 50 as a maximum port count in the model. The grouping information is used to combine things into about 50 ports at most. He said including more ports typically increases simulation time without providing much improvement in accuracy. He noted that this is something of a best practice recommendation based on the current state of the industry, not a hard limit imposed by the SPIM BIRD draft. Kinger said he was expecting that models would use the hierarchical file naming capabilities in IBIS to group the SPIM model associated files (e.g., at least two files for each power rail containing the S-parameter and R network to be used for for AC and DC simulation respectively) in a common subdirectory. Kinger asked if the [Voltage List] keyword should be provided once each [Begin Chip SPIM] [End Chip SPIM] block, or if we should list it independently for each power rail's [Begin SPIM] [End SPIM]. Arpad said that if they don't require any independent configuration information for each power rail, then we could just list it once. Bob and Arpad offered several editorial suggestions. They recommended the terms "phase 1" for AC and "phase 2" for DC be removed, as AC and DC are handled in this first proposal. Bob noted that whether these keywords are listed as "Required:" will have to be reviewed, as none of them are required in general, but many of them are required if a [Begin Chip SPIM] [End Chip SPIM] block exists. Kinger said he would send draft1 to the ATM mailing list after incorporating the suggestions from the meeting. He and Arpad asked everyone to review it and provide feedback. - Bob: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Kinger to send draft1 of the SPIM BIRD to the ATM list. ------------- Next meeting: 13 September 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives